ICAP Interface Support

 

 

This chapter provides information on configuring the external Active Content Filtering servers for a core network service subscriber. This chapter also describes the configuration and commands that are used to implement this feature.

It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in respective product Administration Guide, before using the procedures in this chapter.

 

Supported Networks and Platforms

This feature supports ST16 and Cisco® ASR 5000 Chassis for the core network services configured on the system.

 

Licensing

External Content Filtering Server support through Internet Content Adaptation Protocol (ICAP) interface is a licensed feature.

To enable this feature on your chassis you must install one of the following licenses, along with other required core network and in-line service licenses:

•	Cisco PID [ ASR5K-00-CS01ICAP ] Content Filtering ICAP Interface, 1K sessions, or Starent Part Number [ 600-00-7578 ] Content Filtering ICAP Interface, 1K sessions.

•	Cisco PID [ ASR5K-00-CS10ICAP ] Content Filtering ICAP Interface, 10K Sessions, or Starent Part Number [ 600-00-8530 ] Content Filtering ICAP Interface, 10K Sessions.

For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.

 

ICAP Interface Support Overview

This feature supports streamlined ICAP interface to leverage Deep Packet Inspection (DPI) to enable external application servers to provide their services without performing DPI, and without being inserted in the data flow. For example with an external Active Content Filtering (ACF) Platform.

A high-level view of the streamlined ICAP interface support for external ACF is shown in the following figure:

High-Level View of Streamlined ICAP Interface with external ACF

The system with ECS is configured to support DPI and the system uses this capability for content charging as well.

If a subscriber initiates a WAP (WAP1.x or WAP2.0) or Web session, the subsequent GET/POST request is detected by the DPI function. The URL of the GET/POST request is extracted and passed, along with subscriber identification information and the subscriber request, in an ICAP message to the application server. The application server checks the URL on the basis of its category and other classifications like, type, access level, content category and decides if the request should be authorized, blocked, or redirected by answering to the GET/POST with:

•	A 200 OK message if the request is accepted

•	A 302 Redirect message in case of redirection. This redirect message includes the URL to which the subscriber should be redirected

•	A 403 Denied message is the request should be blocked

Depending on the response received, the system with ECS will either pass the request unmodified, or discard the message and respond to the subscriber with the appropriate redirection or block message.

Content charging is performed by the Active Charging Service (ACS) only after the request has been controlled by the application server. This guarantees the appropriate interworking between the external application and content-based billing. In particular, this guarantees that charging will be applied to the appropriate request in case of redirection, and that potential charging-based redirections (i.e. Advice of Charge, Top Up page, etc.) will not interfere with the decisions taken by the application server.

Functions of the ACF include:

•	Retrieval of subscriber policies based on the subscriber identity passed in the ICAP message

•	Determining the appropriate action (permit, deny, redirect) to take for the type of content based on subscriber profile

•	Communication of the action (permit, deny, or redirect) decision for the URL back to the ACS module

 

Failure Action on Retransmitted Packets

ICAP rating is enabled for retransmitted packet when default ICAP failure action was taken on an ICAP request for that flow. ICAP default failure action is taken on the pending ICAP request for a connection when the connection needs to be reset and there is no other redundant connection available. For example, in the ICAP request timeout and ICAP connection timeout scenarios. In these cases the retransmitted packet in the uplink direction is sent for ICAP rating again.

In case of WAP CO, uplink retransmitted packet for the WAP transactions for which ICAP failure action was taken will be sent for ICAP rating. WSP header of the retransmitted packet is not parsed by the WSP analyzer. The URL received in the previous packet for that transaction is used for ICAP rating. If failure action was taken on multiple WTP transactions for the same flow (case: WTP concatenated GET request) then uplink retransmitted packet for each of the transaction is sent for rating again.

In case of HTTP, uplink retransmitted packets for the HTTP flow on which ICAP failure action is taken is sent for ICAP rating. The URL present in the current secondary session (last uplink request) is used for ICAP rating. However, if there were multiple outstanding ICAP request for the same flow (pipelined request) then for the retransmitted packet the URL that will be sent for rating will be that of the last GET request.

Retransmission in various cases of failure-action taken on re-transmitted packets when the ICAP response is not received for the original request and the retransmitted request comes in:

•

WSP CO:

•

Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked. It is possible that the WAP gateway sends the response for the permitted GET request. Hence, there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.

•	Content Insert: The retransmitted packet is not sent for ICAP rating.

•	Redirect: The retransmitted packet is not sent for ICAP rating.

•	Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked.

•	Terminate flow: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed or blocked. The WAP gateway may send an Abort transaction for this GET request if the WSP disconnect packet sent while terminating the flow is received by the WAP gateway.

•

HTTP:

•

Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the last HTTP GET request. It is possible that the HTTP server sends the response for the permitted GET request. Hence there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.

•	Content Insert: Retransmitted packets are dropped and not charged.

•	Redirect: Retransmitted packets are dropped and not charged.

•	Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction allowed/blocked.

•	Terminate flow: Retransmitted packets are dropped and not charged.

 

Configuring ICAP Interface Support

This section describes how to configure the Content Filtering Server Group (CFSG) through Internet Content Adaptation Protocol (ICAP) interface between ICAP client and ACF server (ICAP server).

Important: This section provides the minimum instruction set for configuring external content filtering servers on ICAP interface on the system. For more information on commands that configure additional parameters and options, refer to CFSG Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.

To configure the system to provide ICAP interface support for external content filtering servers:

Step 1

Create the Content Filtering Server Group and create ICAP interface with origin (local) IP address of chassis by applying the example configuration in the Creating ICAP Server Group and Address Binding section.

Step 2

Specify the active content filtering server (ICAP sever) IP addresses and configure other parameters for ICAP server group by applying the example configuration in the Configuring ICAP Server and Other Parameters section.

Step 3

Configure the content filtering mode to external content filtering server group mode in ECS rule base by applying the example configuration in the Configuring ECS Rulebase for ICAP Server Group section.

Step 4

Optional. Configure the charging action to forward HTTP/WAP GET request to external content filtering servers on ICAP interface in Active Charging Configuration mode by applying the example configuration in the Configuring Charging Action for ICAP Server Group section.

Step 5

Verify your ICAP interface and external content filtering server group configuration by following the steps in the Verifying the ICAP Server Group Configuration section.

Step 6

Save your configuration as described in the Verifying and Saving Your Configuration chapter.

 

Creating ICAP Server Group and Address Binding

Use the following example to create the ICAP server group and bind the IP addresses:

configure

  context <icap_ctxt_name> [ -noconfirm ]

     content-filtering server-group <icap_svr_grp_name> [ -noconfirm ]

        origin address <ip_address>

        end

Notes:

 

•	<ip_address> is local IP address of the CFSG endpoint.

 

Configuring ICAP Server and Other Parameters

Use the following example to configure the active content filtering (ICAP server) and other related parameters:

configure

  context <icap_context_name>

     content-filtering server-group <icap_server_grp_name>

        icap server <ip_address> [ port <port_number>][max <max_msgs>][priority <priority>]

        deny-message <msg_string>

        response-timeout <timeout>

        connection retry-timeout <retry_timeout>

        failure-action { allow | content-insertion <content_string> | discard | redirect-url <url> | terminate-flow }

        dictionary {custom1 | custom2 | standard}

        end

Notes:

 

•	In StarOS 8.1 and later, a maximum of five ICAP servers can be configured per Content Filtering Server Group. In StarOS 8.0, only one ICAP Server can be configured per Content Filtering Server Group.

•	The maximum outstanding request per ICAP connection configured using the optional max <max_msgs> keyword is limited to one. Therefore, any other value configured using the max keyword will be ignored.

•	Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:

url-extraction { after-parsing | raw }

By default, percent-encoded hex characters in URLs sent from the ACF client to the ICAP server will be converted to corresponding ASCII characters and sent.

 

Configuring ECS Rulebase for ICAP Server Group

Use the following example to configure the content filtering mode to ICAP server mode in the ECS rulebase for content filtering:

configure

  require active-charging [optimized-mode]

  active-charging service <acs_svc_name> [-noconfirm]

     rulebase <rulebase_name> [-noconfirm]

        content-filtering mode server-group <cf_server_group>

        end

Notes:

 

•	In StarOS 8.1, the optimized-mode keyword enables ACS in the Optimized mode, wherein ACS functionality is managed by SessMgrs. In StarOS 8.1, ACS must be enabled in the Optimized mode.

•	In StarOS 8.3, the optimized-mode keyword is obsolete. With or without this keyword ACS is always enabled in Optimized mode.

•	In StarOS 8.0 and StarOS 9.0 and later, the optimized-mode keyword is not available.

 

Configuring Charging Action for ICAP Server Group

Use the following example to configure the charging action to forward HTTP/WAP GET request to ICAP server for content processing:

configure

  active-charging service <acs_svc_name>

     charging-action <charging_action_name> [ -noconfirm ]

        content-filtering processing server-group

        end

 

Verifying the ICAP Server Group Configuration

This section explains how to display and review the configurations after saving them in a .cfg file as described in Verifying and Saving Your Configuration chapter of this guide and also to retrieve errors and warnings within an active configuration for a service.

Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.

These instructions are used to verify the configuration for this feature.

Step 1

Verify your ICAP Content Filtering Server Group configuration by entering the following command in Exec Mode:

show content-filtering server-group

The following is a sample output. In this example, an ICAP Content Filtering server group named icap_cfsg1 was configured.

Content Filtering Group:     icap_cfsg1

  Context:                     icap1

  Origin Address:              1.2.3.4

  ICAP Address(Port):          1.2.3.4(1344)

  Max Outstanding:             256

  Priority:                    1

  Response Timeout:      30(secs)      Connection Retry Timeout:      30(secs)

  Dictionary:                   standard

  Timeout Action:               terminate-flow

  Deny Message:                 "Service Not Subscribed"

  URL-extraction:                after-parsing

  Content Filtering Group Connections: NONE

Total content filtering groups matching specified criteria:  1

Step 2

Verify any configuration error in your configuration by entering the following command in Exec Mode:

show configuration errors

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883